This feels different than many open source projects. Especially for a relatively new and also broad umbrella foundation, I worry that this freely given perpetual membership even if only a weak badging, might encourage confusion on what is or is not officially part, sponsored by, under consideration within the auspices of the foundation. That type of confusion and contention has already been a bit of a problem for the OpenSSF org.

I personally would prefer a simple and collaborative open membership. But I also want clarity of mission and propose and that to be easily discovered and difficult to confuse.

Perhaps this is less of an issue if leadership (ie: certain team memberships in the org?) roles are clearly marked. But GitHub team memberships tend to be opaque. I’m not sure if there is maybe an org setting which would allow team members be viewed by non org members. Or if not…alternatively if anybody can get org membership, I guess anybody could ask for org membership to be able to see team membership? Or GH team members defined by in repo yaml configs? Still not great UX though.

Except perhaps in orgs with a very small number of members, it's unlikely that anyone would interpret anything about an individual's org membership alone beyond baseline participation. (And if they did, that would be quite misguided.)

@tpepper OpenSSF is not itself an open source project, and this is how TC39 operates, which I think is more analogous.

I agree that it's not great UX that the only way to be on a team is to be in the org, but it seems a worthy tradeoff for me.

Following PLP(below) projects will need teams for each access level (eg scorecard-read, scorecard-traige, scorecard-write, scorecard-maintain)

In the extreme yes, but we'd only create these as needed, since most repos don't need this granularity atm.

I don't think this is just an extreme case. Take a look at the BP-WG group:
https://github.com/orgs/ossf/teams/wg-best-practices/members
https://github.com/orgs/ossf/teams/wg-best-practices/repositories

All those people who had some kind of access to any of the 6 repos now have write/maintain access to all of them. In an effort to reduce the manual configuration of groups. repos and access-levels will be consolidated and people will be getting access they don't need and/or shouldn't have.

Sure, that's a fair point. However, when I created that specific team i was told that all members should have Write. There's a tradeoff here balancing convenience and "least privilege", and since Write is a pretty non-dangerous privilege, it seemed like a worthy one.

If we end up needing to do this for the majority of repos, then we should absolutely document it as the default approach, but we're not there yet today.

There's a tradeoff here balancing convenience and "least privilege"

This is exactly my point. Without granular teams per repo and access level, we are reducing our security and going against PLP. Without some sort of automation or config-as-code way to manage the teams, convenience will undermine the goals of the teams mandate.

I think that is something we can iterate on as well - automation is worth considering but in practice is often overkill, and the goal here isn't strict PLP, but a safer balance.

How to we enforce this?

Allstar has a policy to nag if any individuals have write/admin access, we could use this.

We already have an auditing tool; see https://github.com/ossf/github-org-access-scraper.

Looks like Maintain doesn't allow setting up branch protection. A lot of or repos don't have this setup Will org admins set this up, if we don't have Admin access to our own repos?

Yes; org admins (the PM team, primarily) will be available to do any repo administration that repo owners lack access to do.

This doesn't seem like a tenable solution. If encouraging project owners to not have admin on the repos, they really need an easy way to read settings, and an automated way to apply changes.
https://gitlab.eclipse.org/eclipsefdn/security/otterdog is a tool we could use to do this, for example.

This is definitely something we can iterate on; in my experience managing large github orgs (or in my own 400+ single-maintainer projects), maintainers rarely need Admin more than a handful of times over the lifetime of a repo, and as long as the friction is minimal when it's needed, it's "fine".

Note also that the language here is "prefer"; if anyone feels strongly that they want admin over a repo, then imo they can have it.